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(54) Check verification system and method 

(57) A method and system for determining the 
negotiability of checks drawn on any account from any 
bank or other financial institution based on a compari- 
son against stored information on whether or not checks 
previously drawn on that account have cleared and 
were paid includes a database having two related 
tables. A table of active accounts at any bank is gener- 
ated by recording account information from checks pre- 
sented for negotiation at a second bank. If the check is 
not returned after a predetermined number of days (i.e., 
the check is paid), the record is updated to show that 
the account is "in good standing". A separate table of 
accounts that are not in good standing is generated 
from returned unpaid checks. For each new entry in the 
table of accounts that are not in good standing, a corre- 
sponding record in the active account table is updated 
to show a status of "not in good standing". Also, for each 
entry in the active file that changes its status from 
"active" to "in good standing", any corresponding entry 
in the table of accounts that are not in good standing is 
deleted. Information concerning whether a checking 
account is in good standing or is not in good standing 
may be used by the financial institution or by merchants 
or other third party providers to determine, in real time, 
if they should accept a check as payment by querying 
the database so formed. 
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Description 

[0001] The present application claims the benefit of 
priority from U.S. Application Serial No. 60/161,254, 
filed October 25, 1999. 

[0002] The present invention relates generally to a 
method and system for determining whether a check 
~ - used-as payment for-goods and services willJikely be 
paid. More particularly, but not exclusively, the invention 
relates to a system and method for developing a data- 
base of checking account information from checks 
received for processing and for comparing a check pre- 
sented to a merchant or financial institution against that 
database to determine whether or not the account is in 
good standing. . The database is populated with infor- 
mation obtained by tracking checks that are negotiated 
by financial institutions to determine if they are paid or 
are returned unpaid. The invention allows a financial 
institution or other business accepting checks to make 
available data concerning any checking account from 
any financial institution for which it has attempted to 
negotiate payment. 

[0003] Many businesses and consumers pay for 
goods and services with checks, and many businesses 
and merchants accept checks for payment. The use of 
checks provides a significant convenience by making it 
possible to purchase goods and services or pay bills 
without having to tender cash for each transaction. 
However, accepting checks exposes a business or mer- 
chant to the risk that the check will be bad, or "bounce", 
and will not be honoured by the payer's bank. This typi- 
cally occurs in cases where the account on which the 
check was drawn has insufficient funds, or if the check 
is a forgery, in most cases where a check is bad, it may 
be difficult to collect payment from the payer or repos- 
sess goods purchased with the bad check. 
[0004] In light of the potential exposure to losses 
associated with accepting checks, businesses have 
sought ways to accurately differentiate between good 
checks and bad checks. Accuracy is important or even 
essential because businesses want to reject as many 
bad checks as possible and limit the number of good 
checks rejected. Generally, the decision to accept or 
reject a check must be made prior to completion of the 
transaction, and must be made quickly while the payer 
waits. * 

[0005] In order to provide businesses with greater 
levels of confidence regarding acceptance of checks 
presented by payers, several companies offer such 
businesses check verification or guarantee services. 
With check "verification'*, a business relies on an author- 
isation received from the check verification company 
(e.g., in the form of an authorisation code) to decide 
whether to accept or reject the check. However, the 
business retains the risk of loss if the check turns out to 
be bad. In most cases, the business is charged a flat fee 
for each check verification. 

[0006] With check "guarantee" companies, the 



company will actuaJly purchase the check from the busi- 
ness if an approved check turns out to be bad. This 
ensures that the business will not suffer a loss if it 
accepts a check that has been approved by the check 
5 guarantee company. In most cases, the business is 
charged a discount fee equal to a percentage of the 
value of each guaranteed check. 

[0007] . ..These. check acceptance (verification and. 

guarantee) companies provide authorisation codes in 
io response to transaction data, such as the transit ABA 
number and account number for the check and the pur- 
chase amount, provided by the business. Typically, the 
acceptance companies will determine the authorisation 
codes by searching a database for negative information, 
15 such as outstanding bad checks, associated with the 
checking account number or identification data (e.g., 
driver's license number). This data is received from var- 
ious participating banks and is then analysed to deter- 
mine the probability that the current check will be bad. 
20 [0008] Even with the prevalent use of check accept- 
ance services, it is estimated that financial institutions 
and merchants incur losses from bad checks amounting 
to $13 billion dollars a year. This is largely attributable to 
the paucity of data available to the acceptance compa- 
25 nies. 

[0009] The ability of the check acceptance compa- 
nies to collect checking account data is constrained by 
the number of banks and financial institutions that sub- 
scribe to their services and provide their account data 
30 as well as the ability of those banks and financial institu- 
tions to provide data concerning all of their accounts. 
For example, many businesses which supply data to 
acceptance companies limit the data on accounts that 
are not in good standing. Therefore, both financial insti- 
35 tutions and businesses repeatedly incur losses from 
bad checks written on the same accounts. 
[0010] In addition, today, there are no databases, of 
any significant size, that provide information about 
checking account holders including names and 
40 addresses along with bank account numbers. For 
example, a major printer of checks may attempt to build 
such a database, but it would require the consent of 
every bank for whom it prints checks, to use of its data 
and there is no capability for obtaining information about 
45 accounts that get their checks printed privately. 

[0011] What is desired is a comprehensive data- 
base that can provide current information about the sta- 
tus of any checking account, before a business or 
merchant accepts a check as payment and before a 
so financial institution negotiates the check. The database 
is generated by tracking checks received for processing, 
rather than by information received from the banks or 
financial institutions. Such a database would signifi- 
cantly reduce both financial institution and business 
55 losses from returned and unpaid checks. 

[0012] The invention described herein outlines a 
methodology and a system construction for establishing 
a comprehensive database of checking accounts. The 
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database contains records of checking accounts, at 
both financial institutions that contribute data and those 
that do not, that are known to be "in good standing" and 
those accounts that are either closed or designated "not 
in good standing". 

[0013] Generally speaking, aspects of the present 
invention are directed to a method and system for veri- 
fying and authenticating negotiable -checks, drawn-on- 
any account from any financial institution based on 
stored information on whether or not checks drawn on 
that account in the past have cleared and were paid. 
More specifically, aspects of the invention herein are a 
method and system for creating and maintaining a data- 
base comprising data representative of known accounts 
which are "in good standing", and data representative of 
accounts known to be "not in good standing" or closed 
accounts. 

[001 4] While banks typically know the status of their 
own customers' checking accounts, they do not keep 
records of whether checks drawn on accounts at other 
banks were paid or returned. Furthermore, large busi- 
nesses that accept many checks may not be able to effi- 
ciently track bad accounts. The present method and 
system differentiates itself significantly from conven- 
tional check acceptance databases by not requiring 
either the check writer's bank or any other business to 
submit account data. Rather, a financial institution or 
other business operating the method and system of the 
invention collects data from all of the checks it receives 
from its depositors or customers for payment or 
processing. 

[0015] Although the system of the invention can be 
used by a single financial institution or large company, it 
becomes even more powerful and can advantageously 
be used by a group of subscribing financial institutions 
and other companies as well. The greater the number of 
financial institutions and companies participating in 
such a system, the greater the number of checking 
accounts that will be included in the database, because 
each time a check is deposited for payment or process- 
ing to any participating financial institution or submitted 
to the large company, data on that account may be col- 
lected. 

[0016] Additional data records can come from any 
subscribing financial institution which process checks 
for itself or on behalf of other businesses, for example, 
checks used to pay credit card bills, mortgages, insur- 
ance bills and etc. Also, each participating financial 
institution may directly add its own accounts to the data- 
base, and may optionally maintain an update of the 
account status. Large companies may also participate 
in the system independently of whether their financial 
institutions participate. 

[0017] The information about whether a checking 
account is in good standing, or is not in good standing 
can be used by the financial institution or by merchants 
or other third party providers accessing the system to 
determine in real time if they should accept a check as 



payment, by querying the database. Thus,' the merchant 
can mitigate the risk of loss that the check will be unpaid 
by checking to see that the checking account being 
drawn upon is known to be active (at least as of the last 

5 record update date) and preferably, in good standing. 
[001 8] Advantageously, this invention provides for a 
database of information about checking accounts resid- 
..ingJn banks that do not expressly, consent to allowing 
the use of this information. 

io [0019] Therefore, an aspect of the invention pro- 
vides a method and system for determining whether a 
check is good using a comprehensive database includ- 
ing data representative of all active checking accounts, 
including an indication of whether each account is in 

is good standing. 

[0020] In another aspect of the invention there is 
provided a method and system for determining whether 
a check is good using a comprehensive database 
including data representative of all checking accounts 

20 that are not in good standing or are closed. 

[0021] A further aspect of the invention seeks to 
develop and maintain such a database without the need 
for any bank or other financial institution to provide infor- 
mation about their own checking accounts. 

25 [0022] A still another aspect of the invention allows 
a business to verify in real time that a check presented 
as payment for goods and services is from a known 
active account, that is in good standing. 
[0023] A still further aspect of the invention main- 

30 tains current data representative of every checking 
account in the database by tracking the results of the 
negotiation of each check presented for payment by 
subscribing financial institutions. 
[0024] A yet another aspect of the invention collects 

35 checking account information about checking accounts 
residing in banks that do not expressly consent to allow- 
ing the use of this information. 

[0025] A yet further aspect of the invention collects 
checking account information including the checking 
AO account holder's name and address, along with the 
checking account number, from the checks received for 
payment or processing. 

[0026] Still other aspects and advantages of the 
invention will in part be evident and will in part be appar- 

45 ent from the specification. 

[0027] Embodiments of the invention accordingly 
comprises the several steps and the relation of one or 
more of such steps with respect to each of the others, 
and the system embodying features of construction, 

so combinations of elements and arrangement of parts 
which are adapted to effect such steps, all as exempli- 
fied in the following detailed disclosure, and the scope 
of the invention will be indicated in the claims. 
[0028] For a fuller understanding of embodiments 

55 of the invention, reference is had to the following 
description, taken in connection with the accompanying 
drawings, and provided by way of example only, in 
which: 
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Figure 1 A is a flowchart depicting the steps for gen- 
erating an Active Account database of checking 
account information in accordance with one 
embodiment of the method of the invention; 
Figure 1 B is a flowchart depicting the steps of gen- 5 
erating a Not in Good Standing database of check- 
ing account information in accordance with another 

- embodiment of the method of the invention; 

Figure 2A is a flowchart depicting the steps of 
updating a Not in Good Standing database of 10 
checking account information in accordance with 
yet another embodiment of the method of the inven- 
tion; and 

Figure 2B is a flowchart depicting the steps of 
updating an Active Account database of checking 75 
account information in accordance with still another 
embodiment of the method of the invention. 

[0029] At the heart of the system and method of 
embodiments of the present invention is a database of 20 
active account information representative of known 
checking accounts. The database can be used by mer- 
chants and other businesses to ascertain whether a 
check being offered as payment is known to be active 
and preferably in good standing. In a preferred embodi- 25 
ment of the invention, the database of the system com- 
prises either a single table of active account 
information, or two related tables, one of active account 
information and one of accounts that are not in good 
standing. 30 
[0030] A table of known active accounts at any bank 
is developed by the financial institution operating the 
system as it accepts and/or processes checks depos- 
ited by its customers for payment in the ordinary course 
of business. An electronic record of each check depos- 35 
ited for payment, including the transit ABA number and 
account number and the date the check is deposited, is 
stored in the Active Account table and an "active" status 
indicator is set. 

[0031] Depending upon the particular financial insti- 40 
tution presenting the check and the particular bank from 
which funds will be drawn, the financial institution pre- 
senting the check can estimate the number of days it will 
take to be notified that the check is being returned 
unpaid by the paying bank. Thus, in addition to the 45 
record containing the day the check was deposited, the 
record will contain an estimate of the number of days it 
will take to return that check. Once that number of days 
has passed, and the paying bank has not returned the 
check, the record status can be updated to show that so 
the account is "in good standing", i.e., checks are being 
paid against that account. Additionally, if other financial 
institutions and large companies who participate in the 
system contribute records of their own check process- 
ing activities to a central database, a fairly complete 55 
table of active checking accounts can be easily devel- 
oped. Notably, this database is generated from checks 
presented for payment or processing and without any 
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financial institution having to contribute information 
about its own checking accounts it maintains. 
[0032] Similarly, in an alternative embodiment of 
the invention, a separate table is maintained in the data- 
base of accounts at any bank that are not in good stand- 
ing. Approximately 1% of all checks negotiated are 
returned by the paying bank because the underlying 
account has insufficient funds, or the check drafter's sig- 
nature is irregular, or the account is assigned, blocked 
or closed. For each check that is returned by the paying 
bank, the financial institution operating the system of 
embodiments of the invention generates an electronic 
record of the account number (transit ABA) in a table 
designating accounts that are not in good standing. By 
aggregating these electronic records, the financial insti- 
tution can develop a table of accounts from any bank 
that are not in good standing. Again, as more financial 
institutions and large companies participate in the serv- 
ice, the resulting database will become more inclusive. 
[0033] In the normal course of business, accounts 
may change their status frequently. For example, many 
accounts that are in the "not in good standing" category 
change their status to "in good standing". Also, a small 
percentage of accounts in the "in good standing" cate- 
gory change their status to "not in good standing". In 
order to maintain current information in the two data- 
base tables, information must be passed between them. 
For example, for each new entry in the table of "not in 
good standing" accounts, a corresponding record in the 
table of active accounts must be updated to show a sta- 
tus of "not in good standing" or, such record may be 
deleted. Also, if the number of prescribed days calcu- 
lated to receive a returned check has passed and the 
check has not been returned, then the status of that 
record in the table of active accounts changes from 
"active" to "in good standing". Finally, if three years have 
passed since the last entry of an "item for that checking 
account, that record is preferably deleted. 
[0034] The table of "not in good standing" accounts 
is also updated. For each entry in the table of active 
accounts that changes its status from "active" to "in 
good standing", any corresponding entry in the table of 
"not in good standing" accounts is deleted. Additionally, 
if three years have passed since the last time a check 
was returned on this account, the record of that account 
in the table of "not in good standing" accounts may be 
deleted. 

[0035] Certain individual features of a preferred 
embodiment of the invention will now be described. 

Developing a database of active accounts at all financial 
institutions: 

[0036] In the normal course of doing business, a 
financial institution accepts and/or processes checks 
drawn on other financial institutions throughout the 
United States and to a lesser extent, throughout the 
world. During its daily processing of checks, financial 
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institutions or third party service providers create elec- 
tronic records of all of the checks presented that day. 
Typically, those records are used for posting the checks 
to accounts, processing returned items and preparing 
cash tetters. 5 
[0037] The method and system according to 
embodiments of the present invention involve having a 
financial institution or third party service provider aggre- 
gate the daily records, if multiple financial institutions 
participate, they preferably combine their aggregated 10 
records. The record for each account preferably 
includes the date the account was first entered in the 
database, the most recent date a check was negotiated 
and the dates the status of the account changed to "not 
in good standing". is 
[0038] Eventually, the resulting aggregated data- 
base would desirably contain every account number in 
use at every financial institution in the United States and 
those countries that conform to the ANSI MICR check 
standards. 20 
[0039] Depending upon the particular financial insti- 
tution accepting the check and the ABA Transit number 
and account number on the check negotiated, the 
number of days it will take to be notified that a check is 
being returned is predictable. The record for each check 25 
in the database contains the day the check was negoti- 
ated and an estimate of the number of days it will take to 
return that check. After the number of days has passed, 
and the paying financial institution has not returned the 
check, the file is updated to show that not only is the 30 
account "active" but it is "in good standing" and checks 
are being paid against the account. 
[0040] Importantly, the database includes accounts 
at all financial institutions irrespective of whether that " 
financial institution contributed any data. 35 

Developing a table of accounts that are not in good 
standing: 

[0041] Each day, a financial institution or third party 40 
processor receives checks back for which the paying 
financial institution has refused payment. A participating 
financial institution creates an electronic record of the 
account numbers of these returned checks. By aggre- 
gating these records daily, the financial institution has a 45 
table of all of the accounts that are not in good standing 
throughout the United States. If multiple financial institu- 
tions participate, the resulting database is more inclu- 
sive. Each entry is updated to reflect the most recent 
date. so 

Keeping the table of active accounts up to date: 

[0042] For each new entry in the table of "not in 
good standing" accounts, the status in the table of 55 
active accounts is changed for this account to show a 
status of "not in good standing". 
[0043] If the indicated number of days to receive a 



returned check has passed and the check hasn't been 
returned, the status of the account is changed from 
"active" to "in good standing". 

[0044] Optionally, if three years have passed since 
the last entry of an item, the entry is deleted. 

Keeping the table of "not in good standing" accounts up 
- to date: . . . 

[0045] For each entry in the table of active accounts 
that changes its status to "in good standing", the table of 
"not in good standing" accounts is checked to see if 
there is a record. If there is, the record is preferably 
removed. 

[0046] Optionally, if three years have passed since 
the last time a check was returned on this account, the 
entry or record is preferably removed. 

Other sources of data: 

[0047] In addition to checks which a financial insti- 
tution processes during its normal processing opera- 
tions, there are typically other sources of checks in 
other business lines that the method and system 
according to. embodiment of the present invention can 
use. For example, checks used to pay credit card bills, 
mortgages, insurance bills, etc. 
[0048] Also, it is desirable that large companies and 
public utilities that receive many checks as payment 
participate in the method and system according to 
embodiments of the present invention. 
[0049] Furthermore, it is desirable that each partici- 
pating financial institution add its own accounts to the 
database, although this is not necessary. 
[0050] It is also desirable that processing associa- 
tions, such as check clearinghouses also supply data. 
[0051] Account numbers also appear on ACH 
(Automated Clearing House) transactions. As an origi- 
nating depository financial institution (ODFI), these 
transactions and the return of these transactions pass 
through the financial institution and preferably are 
added to the database. ACH processors may also be 
potential sources of data. 

How a financial institution can use the database: 

[0052] Deposits -- The financial institution may use 
the information in the database to decide whether to 
place a delay on a deposited check or to place an 
extended delay as allowed by Federal Reserve Board 
Regulation CC. 

[0053] Check cashing — The financial institution 
may use the information in the database to decide if it 
will cash a check drawn on another financial institution. 
[0054] Payments -- The financial institution may use 
the information in the database to decide whether it 
should immediately increase the available credit follow- 
ing a payment to a credit card or line of credit. 
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[0055 J Merchant - The financial institution may pro- 
vide the information in the database to merchants or 
third party service providers to help merchants decide if 
they should accept a check from a purchaser. 
[0056] Additional preferred embodiments of the 5 
present invention will now be described. 
[0057] As described above, in one embodiment of 
the present invention, a single database table is used to _ 
store information concerning checking accounts. Mer- 
chants and other businesses deposit checks to their w 
own banks. The bank depositors present the checks to 
the paying banks, i.e., the banks from which the checks 
are drawn, and expect to receive payment. The paying 
banks either pay the checks or return them unpaid. If 
the checks are paid, the depository banks credit the 15 
account of the merchants or businesses that deposited 
the checks. 

[0058] With reference to Fig. 1A, the financial insti- 
tution or large company running the inventive system 
and method begins developing the database of embod- 20 
iments of the invention at a step 10 and receives a 
check from a depositor at a step 12. The financial insti- 
tution or large company enters the check information 
into a database 14 at a step 16. Database 14 typically 
includes the transit ABA number, the account number, 25 
the check number and the date of deposit for that check. 
[0059] Next, at a step 18, the system will calculate 
the number of days measured from the date of deposit 
it takes for a returned check to be received from the pay- 
ing bank. It should be understood that the number of 30 
days to receive a returned check is predictable and is 
dependent on the particular paying bank and the partic- 
ular depository bank. 

[0060] The initial entry of check information in data- 
base 14 (step 1 6) involves a status indicator of "active." 35 
An active indicator on a data record simply means that 
a check having that account number has been entered 
into the system. 

[0061] For each individual data record, the system 
waits the number of days calcu lated i n step 1 8 (step 20). 40 
After the calculated number of days has passed, the 
system determines whether the check has been 
returned by the paying bank at a decision step 22, and 
if the check has not been returned, the system marks 
the status of the record "in good standing" at a step 24. 45 
A status indicator of "in good standing" means that 
recent checks from this checking account have been 
paid by the paying bank. Thus, if a business or mer- 
chant that is trying to determine whether or not to 
accept a check for payment finds that checks for that so 
checking account have been paid recently, this is a good 
indication that the check being offered will also be paid. 
[0062] If, on the other hand, the check has been 
returned at decision step 22, i.e., has not been paid by 
the paying bank, the system will mark the status of that 55 
record "not in good standing" at a step 26. A status indi- 
cator. of "not in good standing" means that checks are 
not being paid on this account at this time. Thus, if a 



merchant or business is trying to determine whether or 
not to accept a check from this account for payment, 
that business or merchant has information that the 
check may not be paid and can insist on an alternative 
form of payment. 

[0063] After marking the status "in good standing" 
at step 24 or "not in good standing" at step 26, the 
_ method.of generating the database is, ended at a step. 
28. 

[0064] It is typical for a financial institution that is 
acting as a depository to process the deposited checks 
and returned checks separately as batch processes. In 
this case, it may be desirable for the system and method 
of embodiments of the present invention to contain two 
separate tables, rather than one. In such a case, one 
table tracks active accounts as checks are deposited 
and the other table tracks accounts that are not in good 
standing. 

[0065] With reference to Fig. 1 B, the method of gen- 
erating a table of "not in good standing" accounts 
begins at a step 30. The financial institution receives 
returned checks from the paying banks at a step 32. 
The check information is entered into a second data- 
base 36 at a step 34. Desirably, second database 36 will 
include the transit ABA number, the account number, 
the check number and the date the check was returned. 
[0066] Optionally, the system will mark the status of 
that checking account "not in good standing" at a step 
38, and then end at a step 40. 

[0067] Now with reference to Fig. 2 A, the system 
reconciles information in each of database 14 and sec- 
ond database 36 and updates them as necessary. The 
method of updating the table of "not in good standing" 
accounts begins at a step 42. The system waits until the 
status of an active account record is changed to "in 
good standing" at a step 44. The system obtains the 
check information from database 14 at a step 46 and 
determines if that record exists in the table of "not in 
good standing" accounts at a decision step 48. 
[0068] If the account does not exist in the table of 
"not in good standing" accounts, i.e., decision step 48 is 
"no," the method ends at a step 52. On the other hand, 
if the record does exist, i.e., decision step 48 is "yes," 
the system deletes the entry from the second database 
table of "not in good standing" accounts 36 at a step 50, 
and then the process ends at step 52. 
[0069] Now turning to Fig. 2B, the method of updat- 
ing the table of active accounts begins at a step 54. The 
system waits until a new record is generated in second 
database 36 at a step 56. The system then obtains the 
check information from second database 36 at a step 58 
and determines whether the table of active accounts 
includes a record of that account at a decision step 60. 
[0070] If the table of active accounts does include 
this account, i.e., decision step 60 is "yes," the system 
marks the status in database 14 "not in good standing" 
at a step 62 and then ends at a step 64. 
[0071] On the other hand, if the table of active 
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accounts does not include that account, i.e., decision 
step 60 is "no," the system performs an error procedure 
at a step 66 before it ends at step 64. Error procedure 
step 66 can be used to determine why the check was 
not already entered in the table of active accounts 5 
before it was presented for payment. Since the system 
and method requires that every check deposited by a 

. business or_ merchant is entered into the.table of active 

accounts prior to it being presented to the paying bank 
for payment, each check that is returned should already w 
have an entry in database 14. Thus, error procedure 66 
can be used to identify whether the check was improp- 
erly returned to the operator of the inventive system or 
where the system and method is not operating properly. 
[0072] Embodiments of the present invention pro- 15 
vide a system and method for accumulating databases 
of information concerning checks presented for pay- 
ment or processing. It will be readily understood that 
such information can further include the name and 
address of the checking account holder, which can be 20 
determined by inspecting the check. In all cases, the 
check contains the check writer's name, his or her 
bank's routing/transit number, his or her account 
number and his or her signature. Typically, the check will 
also contain his or her mailing address. Thus, the sys- 25 
tern operator can easily create databases of these 
names, addresses, bank and account numbers and sig- 
natures. 

[0073] For entities using systems which capture the . 
image of the checks they are processing, the name, 30 
address, bank routing/transit number and account 
number can be captured using readily available soft- 
ware (e.g., optical character recognition software and 
the like) to translate this information, which appears 
graphically on the captured image, into standard alpha- 35 
numeric characters. These alphanumeric characters 
can be stored in the databases, the signature (or a 
derived set of parameters describing the signature) can 
also be stored graphically (the signature) or alphanu- 
merically (the derived parameters). For system opera- 40 
tors that do not use image capture during processing, 
the alphanumeric information can be entered manually. 
[0074] This collected data can be used, for exam- 
ple, as follows: 

45 

a. validation of information provided by an individual 
when he or she opens an account or applies for a 
loan; 

b. validation of information provided by an individual so 
when purchasing goods over the telephone or Inter- 
net; 

c. locating individuals for collections purposes, 
especially in the environment where a merchant 55 
returned a check used to purchase goods at the 
Point of Sale, in truncation process such as that 
authorised under the National Automated Clearing 



House Operating Rules and the merchant no longer 
has the customer's name and address; 

d. to identify potential customers of other banks 
meeting a particular behavioural profile; 

e. to identify potential customers or for purposes of 
creating a direct marketing mailing list; 

f. retrieval and/or validation of a signature on a 
check, application, document, and the like; and 

g. validating checks tendered for payment. 

[0075] It will thus be seen that the aspects set forth 
above, among those made apparent from the preceding 
description, are efficiently attained and effected and, 
since certain changes may be made in carrying out the 
above methods and in the systems as set forth without 
departing from the spirit and scope of the invention, it is 
intended that all matter contained in the above descrip- 
tion and shown in the accompanying drawings shall be 
interpreted as illustrative and not in a limiting sense. 
[0076] It is also to be understood that the following 
claims are intended to cover all of the generic and spe- 
cific features the invention herein described and all 
statements of the scope of the invention which, as a 
matter of language, might be said to fall therebetween. 
[0077] The scope of the present disclosure includes 
any novel feature or combination of features disclosed 
therein either explicitly or implicitly or any generalisation 
thereof irrespective of whether or not it relates to the 
claimed invention or mitigates any or all of the problems 
addressed by the present invention. The applicant 
hereby gives notice that new claims may be formulated 
to such features during the prosecution of this applica- 
tion or of any such further application derived therefrom. 
In particular, with reference to the appended claims, 
features from dependent claims may be combined with 
those of the independent claims and features from 
respective independent claims may be combined in any 
appropriate manner and not merely in the specific com- 
binations enumerated in the claims. 
[0078] Insofar as embodiments of the invention 
described above are implementable, at least in part, 
using a software-controlled programmable processing 
device such as a Digital Signal Processor, microproces- 
sor, other processing devices, data processing appara- 
tus or computer system, it will be appreciated that a 
computer program for configuring a programmable 
device, apparatus or system to implement the foregoing 
described methods is envisaged as an aspect of the 
present invention. The computer program may be 
embodied as source code and undergo compilation for 
implementation on a processing device, apparatus or 
system, or may be embodied as object code, for exam- 
ple. The skilled person would readily understand that 
the term computer in its most general sense encom- 
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passes programmable devices such as referred to 
above, and data processing apparatus and computer 
systems. 

[0079] Suitably, the computer program is stored on 
a carrier medium in machine or device readable form, 
for example in solid-state memory or magnetic memory 
such as disc or tape and the processing device utilises 
-the programor a part thereof to configure, it .for opera-_ 
tion. The computer program may be supplied from a 
remote source embodied in a communications medium 
such as an electronic signal, radio frequency carrier 
wave or optical carrier wave. Such carrier media are 
also envisaged as aspects of the present invention. 

Claims 

1 . A method of determining whether or not a tendered 
check is negotiable comprising the steps of: 

storing in a database information concerning 
checking accounts including a first table of 
checking accounts that are not in good stand- 
ing and a second table of checking accounts 
that are in good standing; 
receiving checking account information 
extracted from a tendered check; 
comparing said checking account information 
from said tendered check to said first table of 
checking accounts, that are not in good stand- 
ing and said second table of checking accounts 
that are in good standing; 
returning an indication that said tendered 
check cannot be verified if said checking 
account information from said tendered check 
matches said first table of checking accounts 
that are not in good standing; 
returning an indication that said tendered 
check can be verified if said checking account 
information from said tendered check matches 
said second table of checking accounts that 
are in good standing; and 
presenting said tendered check for negotiation 
if said indication that said tendered check can 
be verified is returned. 

2. The method of claim 1 , wherein said information 
concerning checking accounts that are not in good 

- standing and checking accounts that are in good 
standing is extracted from checks presented for 
negotiation. 

3. The method of claim 1 or 2, further comprising the 
steps of: 

adding a record of said checking account infor- 
mation from said tendered check to said sec- 
ond table of checking accounts that are in good 
standing and designating said record as active; 



calculating a number of days in which said ten- 
dered check would be returned as unpaid and 
entering said number of days into said record; 
changing said record from active to in good 

5 standing if said number of days have passed 

since said tendered check was presented for 
negotiation and said tendered check has not 

been returned as unpaid; 

removing said checking account information 

io from said tendered check from said first table of 

checking accounts that are not in good stand- 
ing if said first table includes a record of said 
checking account information from said ten- 
dered check, said number of days have passed 

75 since said tendered check was presented for 

negotiation and said tendered check has not 
been returned as unpaid; 
deleting said record from said second table of 
checking accounts that are in good standing if 

20 said tendered check has been returned as 

unpaid; and 

adding a record of said checking account infor- 
mation from said tendered check to said first 
table of checking accounts that are not in good 
25 standing if said tendered check has been 

returned as unpaid. 

4. The method of claim 3, wherein said step of calcu- 
lating includes determining the particular financial 

30 institution presenting said tendered check for pay- 
ment and the particular bank from which funds will 
be drawn. 

5. A system for determining whether or not a tendered 
35 check is negotiable, comprising a database of 

checking account information including a first table 
of checking accounts that are not in good standing 
and a second table of checking accounts that are in 
good standing; means for receiving checking 

40 account information extracted from a tendered 
check; a processor for comparing said checking 
account information from said tendered check to 
said first table of checking accounts that are not in 
good standing and said second table of checking 

45 accounts that are in good standing; means for 
returning an indication that said tendered check 
cannot be verified if said checking account informa- 
tion from said tendered check matches said first 
table of checking accounts that are not in good 

so standing; means for returning an indication that 
said tendered check can be verified if said checking 
account information from said tendered check 
matches said second table of checking accounts 
that are in good standing; and means for presenting 

55 said tendered check for negotiation if said indication 
that said tendered check can be verified is returned. 

6. The system of claim 5, wherein said information 
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concerning checking accounts that are not in good 
standing and checking accounts that are in good 
standing is extracted from checks presented for 
negotiation. 

5 

7. The system of claim 5 or 6, further comprising 
means for adding a record of said checking account 

" information fromsaid tendered check to said sec- 
ond table of checking accounts that are in good 
standing and designating said record as active; w 
means for calculating a number of days in which 
said tendered check would be returned as unpaid 
and entering said number of days into said record; 
means for changing said record from active to in 
good standing if said number of days have passed 15 
since said tendered check was presented for nego- 
tiation and said check has not been returned as 
unpaid; means for removing said checking account 
information from said tendered check from said first 
table of checking accounts that are not in good 20 
standing if said first table includes a record of said 
checking account information from said tendered 
check, said number of days have passed since said 
tendered check was presented for negotiation and 
said tendered check has not been returned as 25 
unpaid; means for deleting said record from said 
second table of checking accounts that are in good 
standing if said tendered check has been returned 
as unpaid; and means for adding a record of said 
checking account information from said tendered 30 
check to said first table of checking accounts that 
are not in good standing if said tendered check has 
been returned as unpaid. 



8. The system of claim 7, wherein said means for cal- 35 
culating includes means for determining the partic- 
ular financial institution presenting said tendered 
check for payment and the particular bank from 
which funds will be drawn. 

40 

9. A computer program comprising computer- or 
machine-readable computer program elements for 
configuring a computer to implement the method of 
any one of claims 1 to 4. 

45 

10. A computer program comprising computer- or 
machine-readable computer program elements 
translatable for configuring a computer to imple- 
ment the method of any one of claims 1 to 4. 



11. A carrier medium carrying a computer program 
according to claim 9 or 10. 
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(54) Check verification system and method 

(57) A method and system for determining the ne- 
gotiability, of checks drawn on any account from any 
bank or otherfinancial institution based on a comparison 
against stored information on whether or not checks pre- 
viously drawn on that account have cleared and were 
paid includes a database having two related tables. A 
table of active accounts at any bank is generated by re- 
cording account information from checks presented for 
negotiation at a second bank. If the check is not returned 
after a predetermined number of days (i.e., the check is 
paid), the record is updated to show that the account is 
"in good standing". A separate table of accounts that are 
not in good standing is generated from returned unpaid 
checks. For each new entry in the table of accounts that 
are not in good standing, a corresponding record in the 
active account table is updated to show a status of "not 
in good standing". Also, for each entry in the active file 
that changes its status from "active* 1 to "irrgood stand- 
ing", any corresponding entry in the table of accounts 
that are not in good standing is deleted. Information con- 
cerning whether a checking account is in good standing 
or is not in good standing may be used by the financial 
institution or by merchants or other third party providers 
to determine, in real time, if they should accept a check 
as payment by querying the database so formed. 
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